Chip 1996 April/CHIP 1996 aprilis (CD06).zip/CHIP_CD06.ISO/hypertxt.arj/9509/HTML3.CD

Text File | 1996-03-02 | 17KB | 274 lines

          @VHTML programozás -- III/3.@N

          @VKészítsünk hipermédiát!@N

              Az  elôzô  két  részben  átnéztük  a  legfontosabb  HTML
          @Ktag@Neket. Most befejezésül  egy lényeges kérdésre  keressük a
          választ: hogyan írjunk jó HTML dokumentumokat?
              A ""jó" alatt egyrészt szintaktikailag helyes,  másfelôl
          az   olvasóközönségünknek   és   magunknak   is    megfelelô
          dokumentumot értek. A dokumentumon eddig egyetlen egy,  HTML
          specifikációnak megfelelô szövegfile-t értettünk.  Mostantól
          hol az egész  munkát fogjuk egyetlen  dokumentumnak nevezni,
          hol  csak  egyetlen  fejezetet  --  ez  a szövegkörnyezetbôl
          egyértelmûen   kiderül.    Hogy   a    sokszor   használatos
          könyv-analógiát  használjuk: eddig  egy fejezetet  neveztünk
          dokumentumnak,  mostantól  az  egész  könyvet,  de  egyetlen
          fejezetét is annak fogjuk nevezni.


          @VSzintaktikus nyavalyák@N

              Nézzük elôször a tipikus szintaktikai hibákat! A legtöbb
          gond a <p> @Ktag@Ngel  van. Elkerülhetô ez, ha  mindig gondolunk
          arra:  a   <p>  @Ktag@N   csak  arra   használatos,  hogy  olyan
          szövegrészeket, amelyek egybefolynának, két részre bontsunk.
          Felesleges  tehát  fejlécek,  listák  stb.  elôtt  és közben
          használni.
              Másik  gyakori  hiba   a  karakter  escape   szekvenciák
          elrontása. Erre  nincs jó  megoldás. Néhány  lényeges dolgot
          újra kiemelnék: a pontosvesszôt  ne felejtsük le a  végérôl,
          ne tegyünk szóközt  a leírásba, végül  vigyázzunk a kis-  és
          nagybetûkre! Egyfajta  megoldás, ha  nem a  karakterneveket,
          hanem az ISO kódokat használjuk. îgy sokkal kevesebbet lehet
          elrontani szintaktikailag, de  hátránya, hogy ha  nem tudjuk
          fejbôl a megfelelô kódot, a kódtáblát kell néznünk.
              A következô probléma a hiperlinkeknél fordul elô. Ha nem
          egy   pontos    dokumentumra,   hanem    egy   könyvtárnévre
          hivatkozunk, ne felejtsük le a  @K/@N jelet a végérôl, bár  lesz
          olyan szerver, ami e nélkül is kiadja a könyvtárlistáját.  A
          hostnevekkel is vigyázzunk: nem elég annyit írni, hogy  @Kwww@N,
          még akkor se, ha általában  csak ezen a néven hivatkozunk  a
          helyi WWW szerverre. Ha hiperlinkbe vesszük bele, írjuk ki a
          teljes nevet (például:  @Kwww.some.site.org@N). A teljes  domain
          név biztosít annyi információt,  hogy az adott hostot  bárki
          megtalálja,  aki  a Neten  van.  Végül még  annyit,  hogy ne
          használjuk a triviális @Klocalhost@N nevet! Ez mindig a  browser
          @Ksite@N-jára fog hivatkozni a szerver helyett. A @Khref@Nek végérôl
          pedig ne hagyjuk le a macskakörmöt! Nagyon könnyû egy sornyi
          URL  végénél elfelejteni,  hogy az  idézôjelben áll,  de  ha
          lehagyjuk, akkor cifra  dolgoknak nézhetünk elébe.  Ugyanígy
          ne  felejtsük el  a lezáró  @Ktag@Neket --  és ha  már  eszünkbe
          jutott, akkor a @K/@N jelet se felejtsük el kiírni. Ezek  lettek
          volna a leggyakrabban elôforduló szintaktikai hibák. Lássuk,
          hogyan érdemes a dokumentumainkat szervezni!
              Ha  a  fejünkben  van  egy  információ,  és   szeretnénk
          másokkal közölni, annak  valószínûleg van szerkezete  is. Ez
          általában egy hierarchikus fa. Ezt meg is tarthatjuk, kiváló
          vázul   szolgálhat   mind  saját   magunknak   a  dokumentum
          készítésekor,  mind az  olvasónak. Három  fô dolgot  érdemes
          szem elôtt tartani:
              @V1.@N az olvasó által elôre elgondolt struktúrát
              @V2.@N a többszörös faszerkezet ötletét
              @V3.@N mekkorák legyenek az egyes dokumentumok, fejezetek


          @VA jól átgondolt struktúrákról@N

              Az  elsô  témánál  újra  csak  azt  tudom  hangsúlyozni:
          figyeljünk oda, kinek írunk.  Ha ôk újak a  témában, érdemes
          szigorúan felépíteni a struktúrát, mert feltehetô, hogy  ezt
          a  struktúrát fogják  megtanulni. Például,  ha szerintünk  a
          téma négy részre bontható, akkor ezt fontos megtanítani.
              Ha azonban az olvasónknak  már van valamilyen tudása  az
          adott témában,  akkor valószínûleg  van egy  struktúra, amit
          elsajátított,  és  így   elvárja,  hogy  hol   találjon  meg
          dolgokat. Nemcsak tudományos témákról lehet szó: például  ha
          egy   számítógépes   játékról   keresek   információt    egy
          számítógépekkel foglalkozó @Ksite@N-on, joggal várom el, hogy  a
          szoftverek alatt  találjam, és  ne a  hardver szekcióban. Ha
          túl  merev  a   struktúránk,  elôfordulhat,  hogy   olvasónk
          képtelen lesz megtalálni bizonyos dolgokat, és feladja --  s
          ez a  legrosszabb, ami  történhet, hiszen  azért dolgoztunk,
          hogy elolvassák írásunkat.
              Az  elôzô  példát  használva:  nem  haszontalan  betenni
          néhány  hardver  linket  is  a  játék  szekcióba,  például a
          joystickekrôl és hasonlókról. Ebben az esetben nagyon erôs a
          kísértés,  hogy  a  saját  struktúránkat  erôltessük  rá   a
          többiekre.  Két megoldás  is van.  Az egyik,  ha egy  azonos
          szemléletû, pontosan meghatározott közösségnek írunk:  ekkor
          az ô szemléletüket használjuk a miénk helyett. Ha ez nem áll
          fent, akkor kénytelenek  vagyunk mindkét --  a magunk és  az
          olvasóink -- szemléletéhez igazodni. Amikor egy  referenciát
          iktatunk be valahová, írjuk le pontosan, mi az, hogy  akinek
          nincs szüksége  arra, átugorhassa,  de akinek  pontosan arra
          van szüksége,  megtalálja. Például:  ""Ha tényleg  szeretnéd
          tudni,  hogyan  mûködik  ez,  akkor  utánanézhetsz  a @KHogyan
          @Kmûködik@N részben". Vagy: ""Lépésenkénti instrukciókat találsz
          az @KOktató@N részben".
              Mivel a hiperlink más  betûtípussal jelenik meg, mint  a
          folyó  szöveg,  célszerû   csak  néhány  szót   hiperlinknek
          kijelölni -- erre elôzô példánkban a ""Hogyan mûködik" és az
          ""Oktató"  részlet  kiválóan  megfelel.  îgy  aztán   mûvünk
          struktúrája  végül  sokkal  bonyolultabb  lesz  az  egyszerû
          fánál,  de  a  részletes  megjelöléseknek  köszönhetôen  nem
          tévednek el olvasóink.


          @VA többszörös fák használata@N

              Itt következik második fô témánk, a többszörös fa. Eleve
          célszerû több  ""gyökér" pontot  megadni. Például  lehet két
          kezdôpont: az egyik egy lépésenkénti oktatás, a másik  pedig
          a  referencia  fa az  egész  anyagra. Természetesen  mindkét
          esetben ugyanaz  az anyag  van a  két fa  ""levelein", de  a
          megközelítés  teljesen  más  --  és  ez  az  elôzôek szerint
          kifejezetten hasznos. Egész egyszerûen ahhoz hasonlíthatjuk,
          amikor  több  index is  van  egy könyvhöz.  (Lásd  az ábrát,
          amelyen  a  többszörös  fa  egy  programozási  dokumentumhoz
          készült.)
              Ha  egy  kezdô  fogja  ezt  olvasni,  ô  valószínûleg az
          oktatónál kezdi, majd a bal oldalon halad lefelé. Végül,  ha
          pontos  részletekre  van  szüksége, a  példák  után  eljut a
          pontos  szintaxishoz.  A  haladó  viszont  valószínûleg vagy
          funkciók szerint, vagy ábécé rendben keres, és ezek  alapján
          jut el a pontos szintaxisig -- ahol példákat is talál --, de
          ott már ugyanazt olvassa, mint a kezdô.


          @VMekkora egy jó dokumentum?@N

              Fontos kérdés  az egyes  dokumentumok mérete.  Ez a HTML
          ajánlásban  nincs  benne.  Egy  dokumentum  lehet   egyetlen
          mondat, rövid megjegyzés vagy  több Mbyte hosszú szöveg  is.
          Azonban  ez  utóbbit  erôsen  javallott  elkerülni.  Érdemes
          figyelembe venni néhány praktikus szempontot a tervezéskor.
              A  legelsô:  a  hosszabb  dokumentum  letöltése hosszabb
          ideig tart. Mivel kevés olyan hosszú szöveg van, ami  teljes
          egészében  mindenkit  érdekel,   érdemes  a  szöveget   több
          dokumentumra  bontani.  Ha  azonban  a  beágyazott   képeink
          növelik  meg  túlzottan  a  dokumentum  méretét,  akkor vagy
          kénytelenek   vagyunk   meghagyni   a   dokumentumot   ilyen
          állapotban, vagy csökkentjük a képek számát és/vagy méretét.
          Ne felejtsük: néha elég egy  pár száz byte-os (!) GIF  is --
          nem kell  mindent 640*480-as  true color  képként beágyazni.
          Arról nem is beszélve,  hogy még a grafikus  browserekben is
          kikapcsolható  a  képek  automatikus  megjelenítése,  és  ha
          információt rejtünk  el a  képekben, sok  olvasó azt  nem is
          fogja  látni.  Emiatt  a  képeknek  elsôsorban  díszítô   és
          magyarázó    szerepe    van.    Nem    célszerû   elsôdleges
          információhordozóként használni.
              Természetesen  van  olyan  eset, amikor  maga  a  kép az
          információ. Ilyenkor ne azt ágyazzuk be, csak egy kis mintát
          róla,  és használjuk  ki az  IMG tag  ALT paraméterét,  hogy
          leírjuk röviden, mirôl  szól a kép.  Ilyenkor az olvasó,  ha
          érdekli a kép által közölt információ, letölti, és utána azt
          valamilyen módon  megnézi. Akit  viszont nem  érdekel ez  az
          információ, nem vesztegeti az idejét és pénzét a letöltésre.
              A másik probléma -- ami elsôsorban a szövegre vonatkozik
          -- a görgetés. Ha nagyon hosszú egy dokumentum, az olvasónak
          nehéz  lesz  elolvasnia  a  sok-sok  képernyônyi   szöveget.
          Számíthatunk arra, hogy aki szöveges browserrel dolgozik  --
          ez itthon igen gyakori,  részben az X terminálok  viszonylag
          magas ára, részben a korlátozott sávszélesség miatt --,  nem
          fog  többet   elolvasni  néhány   képernyônél.  Sôt,   sokan
          mindössze az elsô  képernyôt tekintik meg,  és ha nem  tûnik
          érdekesnek,   akkor  abbahagyják   az  olvasást.   Åltalános
          szabályként  annyit  mondhatunk,  hogy  körülbelül  öt A4-es
          oldalnak   megfelelô   információmennyiség   elegendô    egy
          szövegbe.  Természetesen  gond  lehet  sok  kis   dokumentum
          rengeteg    linkjét    karbantartani.    Ilyenkor   célszerû
          tartalomjegyzék  oldalt  csinálni,  és  erre  irányítani   a
          linkeket.


          @VMég néhány jótanács@N

              îrjuk alá  a dokumentumot.  Nagyon hasznos  egyszemélyes
          homepage-et tartani -- ennek lehetôsége szinte már mindenütt
          ""jár" egy  accounthoz. Ha  ez megvan,  minden dokumentumunk
          alá elegendô  csak a  nevünket beírni  egy a  homepage-ünkre
          mutató   hiperlink  megnevezéseként.   Ráadásul  ha   minden
          dokumentumon szerepel a nevünk, feltehetôen visszajelzéseket
          is kapunk. Ha nagyon nehezen lehet elôásni, hogy ki írta  az
          anyagot, nemigen számíthatunk erre.
              Gondoljunk  arra is,  hogy nem  feltétlenül az  általunk
          elôírt utat követi valaki  egy dokumentum elérésekor --  egy
          URL  megadásával   bármelyik  dokumentumunkat   elérheti  az
          ""elôzôek" elolvasása nélkül!  Nem célszerû így  kezdeni egy
          dokumentumot: ""A következôkben tárgyalandó témánk..."  vagy
          ""Az egyetlen megoldás  erre a problémára...".  Ilyenkor úgy
          segíthetünk  magunkon,  hogy  már  a  dokumentum  elején egy
          visszafelé mutató  linket helyezünk  el, például  ""Vissza a
          tartalomjegyzékbe". Az  elôzô példánkban  jó megoldás,  ha a
          ""problémára" szó egy hiperlink a probléma leírására.
              Ne felejtsük el, hogy HTML nyelvben írunk, aminek  egyik
          fô gondolata az  eszközfüggetlenség! Nem írunk  le olyasmit,
          hogy ""ez a  szöveg 12 pontos  Times New Romans".  Semmilyen
          információt nem rögzítünk a tényleges fizikai kinézetrôl, de
          nem is tehetjük, mert egyszerûen nincs rá módunk. Ne  essünk
          abba a hibába, hogy  egyetlen kliens alá írunk!  Ha olyasmit
          teszünk be  a szövegbe,  hogy ""kattints  ide", ez mindenkit
          zavarni  fog, aki  nem használ  egeret. Ha  azt írjuk,  hogy
          ""válassz  egy  linket  szám  szerint",  tudni  fogják, hogy
          szöveges  kliens  alá  dolgoztunk.  Egyszerûen  hagyjunk egy
          linket  --  az  olvasóink  általában  tudni  fogják,  hogyan
          kezeljék  azt.  Az  igazi  eszközfüggetlenség  az  lenne, ha
          rögtön nyomtatható verziót gyártanánk -- ez sajnos általában
          nem    mûködik,    mert    a    hiperlinkekkel   összekötött
          dokumentumoknak  nincs   valódi  sorrendje.   Ezért  szokott
          születni egy ASCII verziónak nevezett szövegfile változat  a
          fontosabb, nagyobb anyagokból. Ilyenkor a szerzô összehordja
          az anyagot egy file-ba, kiirtja belôle a legtöbb HTML @Ktag@Net,
          és  --  ideális  esetben  --  javít  rajta,  hogy   egyszerû
          szövegként is értelmes maradjon.
              Célszerû tesztelni a dokumentumainkat. Ez azonban idô és
          fáradtság.  Mennyit  célszerû  tesztelni?  Vannak  olyan WWW
          oldalak, amelyek gondos  munkával készültek, de  néhány csak
          tákolmány. Ezzel nem azt  akarom mondani, hogy az  utóbbinak
          nincs  értéke  --  éppen  ellenkezôleg:  a  közölni   kívánt
          információ típusától függôen bôven lehet idônk, vagy esetleg
          semennyi idônk sincs a gondos munkára. Mindig igazodjunk  az
          általunk   közölt   információ   típusához   és   a  várható
          közönséghez! A  Neten a  WWW megjelenése  elôtt a publikálás
          nehézsége,   idôigényessége  miatt   sok  értékes   gondolat
          hozzáférhetetlen  volt  a  nagyközönség  számára.   Manapság
          minden  információnak,  legyen az  akár  egy kósza  gondolat
          file-ba firkantva, vagy sok száz oldalas tanulmány, megvan a
          maga értéke. (Mellesleg ez a  Net nagy baja: szinte már  túl
          sok a hozzáférhetô információ).
              A dokumentum szövegezésébôl, szóhasználatából is kiderül
          sok  minden.  A  Nagybetûvel  írt  Fônevek  Dokumentuma  már
          szabványokat  idéz,  míg   a  gépelési  hibákkal   tarkított
          dokumentum  egyértelmûen  jelzi,  hogy  az  írója  nagyjából
          kihagyta a  tesztelési fázist.  Ha úgy  döntünk, hogy megéri
          tesztelni a dokumentumot, az a legfontosabb, hogy minél több
          browserrel nézzük  meg: hogyan  néz ki,  vannak-e hibák?  Ha
          hozzájutunk,  olvassuk  el  a  szerver  log  file-jait.   Ha
          bizonyos  page-eket  egyáltalán  nem  néznek,  vagy  sok  az
          oda-vissza   ugrálás,  akkor   valamilyen  linkelési   hibát
          véthettünk.  Vigyázzunk  arra,  hogy  amíg  a  szerver   log
          file-jaiban benne vannak a használók tényleges adatai, addig
          azt a megfelelô titkossággal kezeljük! Ha már eltávolítottuk
          ezt   az   információt,   akkor   akár   közölhetjük   is  a
          statisztikákat.
              Végül egy roppant fontos  dolog: ne sértsünk meg  senkit
          és   semmit   dokumentumainkkal!  Tartsuk   be   az  íratlan
          szabályokat, hogy ne okozzunk kellemetlenséget se magunknak,
          se másoknak!
              Kellemes alkotást mindenkinek!
              Befejezésként  egy  utolsó direktíva  a  HTML 1-bôl:  az
          @Kaddress@N. Ez a  dokumentum íróját azonosítja.  A használatára
          egy aktuális példa:
              @K<address> chx@@omega.odin.net </address>@N

          @KNégyesi Károly@N

          @<9509\ABRA.GIF>■■@N  Egy példa többszörös fákra


          @VIrodalomjegyzék@N

              Irodalomjegyzék helyett néhány URL, ahol a témáról angol
          nyelven találhatunk anyagot:

http://www.w3.org/hypertext/WWW/MarkUp/MarkUp.html

http://www.ncsa.uiuc.edu/General/Internet/WWW/HTMLPrimer.html

http://www.ncsa.uiuc.edu/SDG/Software/Mosaic/Docs/fill-out-forms/overview.html

http://wintermute.ncsa.uiuc.edu:8080/map-tutorial/image-maps.html

http://www.w3.org/hypertext/WWW/Provider/Style/Overview.html